3GPP LTE is a project within the 3rd Generation Partnership Project (3GPP) to improve the UMTS (Universal Mobile Telecommunications System) standard to cope with future requirements in terms of improved services such as higher data rates, improved efficiency, lowered costs etc.
When specifying the link layer protocols for LTE, the protocols PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control) and MAC (Medium Access Control) it has been identified that it would be desirable that the protocol headers should, if possible, be octet aligned. It has already been decided that the PDCP header should be octet aligned and it is likely that RLC and MAC also becomes octet aligned. Octet aligned implies that a protocol field occupies a multiple of 8 bits. I.e. a protocol header that is 6 bits is not octet aligned, but if it is 8 or 16 bits or 32 bits it is octet aligned. Generally, a protocol header is octet aligned if the data part starts in an octet aligned position. This concept can be generalized to n-bit alignment. I.e., a protocol header is n-bit aligned if a multiple of n bits occupies the header, where n may be 8, 16, 32 or any other integer value.
The main motivation to have the RLC and MAC headers octet aligned is reduced processing requirements. This is illustrated in FIG. 1. If the headers are not octet aligned which implies that the payload would start in a non-octet aligned position, the receiver of the PDU (Protocol Data Unit) would need to move (shift) the whole payload to a new position in the memory before further processing. This operation, which is illustrated in FIG. 1, often requires significant processing and should therefore be avoided.
A straight forward solution is to design both the RLC and the MAC header to be an integer number of octets. This solution is proposed in document R2-063119, “Byte alignment of L2 header”, Samsung, published Nov. 6, 2006 during 3GPP TSG-RAN2 Meeting #56.
If no consideration to octet alignment is taken, the RLC headers and MAC headers would be optimized to be as short as possible and typically they will not comprise of an integer number of octets. In order to make the RLC and MAC header octet aligned, padding needs to be added in both these layers resulting in an unnecessary large overhead.
This is also complicated by the fact that the RLC and MAC headers do not have a fixed size. For RLC the header size typically varies depending on if concatenation is applied, if segmentation or re-segmentation is applied and potentially also depending on the RLC PDU size. A length indicator indicating the length of the payload is foreseen to be included and the length of the length indicator can potentially vary depending on the RLC PDU size. Similarly, the length of the MAC header varies depending on if multiplexing is applied or not. Thus the total RLC or MAC header can be modeled as a base header that is always present and extensions (denoted E1, E2) that are different depending on the data transmitted in a TTI (Transmission Time Interval). In order to assure that the headers are always octet aligned it may thus be necessary to have both the base headers and the extensions octet aligned. This is illustrated in FIGS. 2a and 2b. FIG. 2a shows a simple case with only the minimum base headers, i.e. where no header extensions are used. Here, padding is added on both RLC and MAC to assure that the respective headers are octet aligned. In another example shown in FIG. 2b, header extensions are used in both RLC and MAC due to that re-segmentation is done in RLC and multiplexing in MAC. This requires that padding is added on several places as illustrated in FIG. 2b. 
It is evident that the straight forward solution of assuring that both the RLC header and MAC header are octet aligned in all cases may require unnecessarily large padding.